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[Declaration of Ricardo Gonzalez) 



I, RICARDO GONZALEZ, being over the age of eighteen and competent to testify, make the 
following declaration: 



1. I hold a bachelor's degree in computer science (BSCS) from Universidad Central de 
Venezuela and also a Master of Arts in Computer Science (MA), from Boston University 
My educational background in computer science, and my experience working with 
trading systems in the last 15 years, has given me knowledge and expertise in the field of 
securities trade automation - a field that almost exclusively involves computer-based 
automation and communication software and hardware. I have created multiple 
integration interfaces between Order Management Systems and trading systems, and this 
has given me knowledge of the software and hardware used by trading systems to 
accomplish trade automation, as well as a detailed and expert understanding of the 
requirements and constraints placed on these systems by traders, portfolio managers and 
other financial services providers. 



2. Since 1994 I have worked in companies specializing in order management systems for 
the securities industry, including Macgregor and Investment Technology Group (ITG), 
the well-known global trading technology company. From 1994 to 2002 I was a senior 
software developer. From 2002 to 2009 I was a software development manager and 
architect for the development of a variety of Order Management Systems. I have over 15 
years experience in the securities trading business, and have substantial expertise in 
financial technology and the firms that use such technology. 
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3. From 1994 to 2009, while working at Macgregor and ITG, I personally designed and 
implemented multiple integration interfaces for three different order management 
systems: Predator, XIP and Triton. Some of these interfaces include posting trades to 
accounting systems, sending clearing data to OASYS, loading and extracting security 
data as well as trading data. 



4. I am very familiar with the order management systems (OMS) available in May 1999, 
when the Shaw et al. patent was first applied for. 



5. I have thoroughly analyzed the Shaw et al. patent application, as well as the SEC 
reference and LimiTrader system discussed therein. 



6. Integrating LimitTrader with an OMS in 1999 would not have been obvious, because the 
LimiTrader system was not designed to be integrated with other systems. Indeed, such an 
integration would have been impossible without a substantial redesign/rewrite of 
LimitTrader. 



7. OMS users demand a single and responsive interface that supports the full trading 
process, including communications among internal parties such as portfolio managers, 
traders and compliance officers, and external parties such as brokers, execution systems, 
settlements systems, and market data providers. Providing such an interface to 
LimiTrader would not have been possible without a substantial redesign and rewrite of 
the LimiTrader system - making integration with an OMS not only impractical, but 
unthinkable. 

8. To satisfy the demands of OMS users, OMS providers invest substantial resources to 
support and integrate all the trading functions and systems required to fully automate and 
speed up the life cycle of a trade. Integration of these real-time workflow systems is a 
very complex undertaking. For integration to be successful, it must be achieved at 
multiple levels: starting with the database and data models that provide a common 
platform for robust semantic interchange across systems, continuing at the messaging and 
service levels that allow systems to cooperate and synchronize their functionality and 
complete a business transaction or sub-process, and ending with a single user interface to 
eliminate the need and risks of duplicate data entry, and the confusion associated with 
distinct interface standards. OMS providers have had to develop most of this 
functionality from scratch, in order to ensure that all elements at each of these levels are 
tightly and correctly integrated in real-time. 
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9. Systems designed in the early 1990s, such as LimiTrader, did not anticipate a future in 
which computer technology would allow for independently developed systems to share 
resources and cooperate in real-time. Closed system design was the prevailing model for 
trading system architecture throughout the early 1990s. Systems were envisioned to be 
stand-alone entities, and only interface with external systems through batch-oriented file 
based import/export utilities. LimiTrader is a shining example of such closed system 
design. 



10. If someone had asked our company in 1999 to integrate an OMS with the LimiTrader 
system, we would have replied that such an integration was not feasible, much less 
obvious , because LimiTrader was a closed system and was not designed to be integrated 
with external systems. And this situation was not uncommon - often, customers would 
request that an OMS be integrated with a proprietary or 3 rd party legacy trading system, 
and we would have to reply that integration was not possible because the trading system 
was designed as a closed system (as LimiTrader was). 



1 1 . The LimiTrader design, the norm at the time, was simply not designed to be integrated 
with an OMS. It lacks all the critical elements required for it to be integrated with an 
OMS, or any other real-time trading workflow system. It does not have an 'open' 
architecture, for example one built around a SQL Relational database that would allow 
other systems to access and modify business data in a transactionally robust manner. It 
also does not have a "real-time" system architecture, which can support event-driven 
message based integration across systems. It does not have the ability to publish events 
or provide a transactionally-safe, service-oriented application program interface (API), 
both of which are important technical requirements for a trading system which will be 
integrated with an OMS. Further, the LimiTrader system does not include support for 
critical business functions such as block trading, 24 hour trading or international trading. 
Without this support, integrating LimiTrader with an OMS would have been impossible, 
because an OMS does provide these critical business functions. 



12. Moreover, the dial-up system used by LimiTrader to communicate with parties would be 
inadequate to support the equity trading decisions and workflows from the OMS. And 
the lack of a real-time API would require a user to go to the LimiTrader terminal just to 
cancel an order, adding unacceptable delays. 

13. Further, LimiTrader' s non-secure matching approach is not suited for the OMS market. 
One of the main benefits of an OMS is that it allows users to retain control of their 
orders until the last possible moment. Equity traders, the majority of OMS users, are 
extremely wary of letting any outside parties learn the contents of their order book. They 
know that any information about their intention to buy or sell shares in the near future 
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can be exploited by 3 rd parties to take advantage of them. They use the OMS as a 
platform for quickly directing and redirecting their orders across any and all liquidity 
sources. It is unthinkable that OMS traders would direct any order flow into a matching 
system such as LimiTrader that notifies multiple parties of possible matches. OMS 
traders would require that they be immediately and simultaneously notified of any 
match, and that only one match be proposed at a time. LimiTrader was not designed to 
support this requirement. Actually, LimiTrader seems to have been designed for a 
market where information leakage is not a great concern, and where participants expect 
and accept that market information will propagate in several minutes rather than in a 
couple of seconds. 



14. There are also a number of other LimiTrader features that clearly point to a system not 
compatible with OMS integration. For instance, an initial capacity for 50 simultaneous 
users is at least a couple of orders of magnitude lower than what is required to support 
actual usage with an integrated OMS. Similarly, LimiTrader' s 30-minute backup 
recovery capability would be unacceptable to the OMS market. Most organizations would 
demand a hot backup to guarantee uninterrupted access. It would be unthinkable for an 
equity trader to have orders in the LimitTrader system in an uncertain state for up to 30 
minutes, because the trader would always be wondering: Did I miss a match? Was the 
order executed? What is my current cash position? It is critical to have such information 
immediately available at all times - and with LimiTrader, it would not be. 



15. In addition, Buy-Side traders typically and properly view the information contained in 
their OMS as key strategic proprietary data. The orders in an OMS represent that action 
that the buy-side firm plans on taking. These orders are usually large and market moving. 
It is the buy-side trader's job to break these large orders into smaller pieces and place 
them with brokers one at a time, minimizing the impact of these orders on the market. 
These large orders can take multiple days to complete when broken up this way, while 
the amounts placed with brokers can be executed typically within a couple of hours. 



16. Buy-side firms worry about information on their orders making its way into the 

marketplace. One of the big concerns is "front-running", where someone with knowledge 
about these orders (and therefore its impact on the market) buys or sells the same security 
before these orders are fully implemented. In this way, they "ride" the impact of those 
orders making a gain or loss at the buy-side firms expense. Buy-side firms think of this as 
information "leakage". 



17. Because of their concern of information leakage, buy-side firms are very cautious about 
what systems they integrate their OMS with, and what type of integration is performed. 
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The OMS contains all of the buy-side firm's orders. If the integration gives this order 
information to another system, the buy-side trader will want to understand how that other 
system will treat this information - to whom will the order information be given and 
under what conditions. If the buy-side trader has a reason to believe that order 
information will be given or available to other market participants, especially the side- 
side (or brokers), they will severely limit what information is sent to that system. It would 
not be uncommon for the trader to insist that the systems NOT be integrated in these 
cases. 



18. The LimiTrader system has exactly the characteristics that would concern a buy-side 
trader. Order information passed to it may be presented to one or more brokers without 
the buy- side trader's knowledge, allowing the broker to benefit from this information. 
The broker could use this information for front-running, providing information about 
market direction to one or more of the buy-side firms competitors, or many other things, 
all designed to take advantage of expected market movement in a particular security. This 
is one reason that integrating LimiTrader with a buy-side OMS would not be obvious. 



19. Further, key portions of the LimiTrader system demand individual interaction with the 
central system - the sort of interaction that is readily available with individuals dialing 
into the central system via their PC, but not via an integrated OMS. 



20. The OMS's in existence as of May 1999 were simply not configured for the features 
described in the SEC reference - i.e., non-automated bid or offer advice and market 
information - nor were they capable of handling such features without prior modification 
to the OMS. Examples of these OMS's, which existed in May 1999 and which were not 
configured to offer non-automated bid or offer advice and market information, include 
the Landmark system from The Long View Group, the Predator system from Macgregor, 
and the Charles River IMS system from Charles River Development. 



21. Thus, users could not have obtained these features via an OMS in existence in May 1999 
and integrated with a central trade-matching system. The features would have been cut 
off unless the OMS had itself been modified before integrating it with the central system 
- and this would not have been obvious, because these OMS's are separately-owned and 
not freely modifiable. In other words, to retain LimiTrader' s individualized features, one 
would have had to first modify the OMS, then also modify the LimiTrader system by 
grafting the OMS onto it. This kind of double, sequential modification would simply not 
have been obvious at the time of the Shaw et al. patent application. 
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22. In sum, integrating a system like LimiTrader to an OMS would have been far from 
obvious in 1999. Indeed, upon consideration of the LimiTrader limitations and the 
critical requirements for OMS real-time trading workflow integration which LimiTrader 
does not meet, such a project would have been unthinkable. 



The undersigned being hereby warned that willful false statements and the like are 
punishable by fine or imprisonment, or both, under 18 U.S.C. §1001, and that such willful 
false statements and the like may jeopardize the validity of this document, declares that all 
statements made of his own knowledge are true and that all statements made on information 
and belief are believed to be true. 





Date 



